Computer-telephony interface (CTI) applications have traditionally communicated with a central call-processing entity, such as a private-branch exchange (PBX), that handles all aspects of call routing, call control, and device control, and that can consequently give them a unified view of all endpoints in the communications system. For example, if an application places a monitor on a device, the central call-processing entity can supply the application with call progress events for all devices on all calls in which the monitored device participates. Or, an application can register with the central call-processing entity to perform routing control for one or more devices, and thus act in substitute capacity for the central call-processing entity to directly receive all call-progress events for those devices.
The Session Initiation Protocol (SIP) is a peer-to-peer protocol that provides signaling and setup for Internet Protocol (IP)-based communications. As such, it requires only a simple core network, with intelligence distributed to the network edge and embedded in endpoints. Communications systems based on the SIP are accompanied by an increasing use of distributed call-process systems wherein no individual call-processing entity is guaranteed to have a view of an entire communication. Applications must therefore find a way of getting their call-control requests to the correct entities, and have a way of getting a unified view of the distributed system.
One approach is to tunnel Computer-Supported Telecommunications Applications (CSTA) information through SIP directly to devices. But this does not provide a unified view of the communications system. A more-popular alternative is to have back-to-back user agent (B2BUA)-style call control wherein the B2BUA is responsible for handling all SIP signaling between both ends of a communication. But most existing back-to-back implementations are based on SIP servlets and not on remote signaling interfaces such as CSTA. Additionally, if a back-to-back-style third-party call-control wants to show a unified view to an application, it has to have every message of every endpoint in the system routed through the B2BUA, which creates scalability issues.